這是一個再平凡不過的星期四下午，你剛花了一整個禮拜，日以繼夜、嘔心瀝血地完成了一份長達二十頁，並且圖文並茂、邏輯清晰、架構完整的產品需求文件。這份文件沒有意外之下，涵蓋了所有可能的使用情境、邊界條件以及錯誤處理機制。你滿意地將它發布在公司的文件管理系統上，還特地加上了清晰的目錄和導覽指引，並在 Slack 頻道公告周知，甚至附上了簡短的導讀和重點摘要。

半小時後，正當你端起咖啡準備稍微放鬆一下時，一位工程師在 Slack 上敲了你一下：「嗨，PM，抱歉打擾你一下，想跟你快速對一下，那個『訂單搜尋』功能，如果使用者沒有輸入任何關鍵字就按搜尋，應該要怎麼處理？是要顯示所有訂單，還是要顯示錯誤訊息，還是有其他處理方式？」

你的太陽穴的青筋不斷抽動，因為這個問題的答案，就清清楚楚地寫在你剛發布的那份需求文件的第五頁，第三點，第二項的規格裡，而且，你還用粗體加了底線 ☺️。

症狀診斷

當團隊有這樣的狀況時，我想可以判定確診為「文件失讀症」。

這個病症，是上一個病症的進階變種：

• 病症 12 的根源，是資訊「送不到」。
• 而這個病症的根源則是資訊已經送達了，但團隊成員卻選擇了 「不去拿」或「懶得拿」 或「拿不到」。

病根通常有兩個，而且往往是相輔相成的：

1. 文件本身的問題
   你的 PRD 可能寫得像一本沒有目錄的百科全書，資訊雜亂無章，或是文件的內容模式，跟工程師的閱讀習慣有根本上的落差。這讓團隊覺得「與其花半小時在裡面大海撈針，不如直接問你比較快」。
2. 團隊習慣的問題
   團隊過去可能習慣了「口頭溝通」的模式，或者，過去的文件常常更新不及，導致他們對文件的信任度早已破產。

所以當你發現明明已經寫好文件，但是工程師總是習慣把你當做人肉解答機不斷提出問題，那麼在翻白眼想抱怨以前，我們不如思考該如何幫助工程師建立一個讓「看文件」比「直接問你」更有效率的習慣。

處方籤

第一劑：請先診療自己的「文件」

在刮別人鬍子前，要先把自己的刮乾淨，所以當然在我們想要求團隊看文件之前，先誠實地問自己三個問題：

1. 我的文件好找嗎？ 是否有統一的存放位置？是否有清晰的目錄結構？
2. 我的文件好讀嗎？ 工程師是視覺型思考者，他們喜歡看的是流程圖、狀態圖、表格，而不是充滿形容詞的長篇大論。我的 PRD 是否圖文並茂？還是只有密密麻麻的文字？
3. 我的文件可信嗎？ 當需求有變更時，我是否總是第一時間更新文件，確保它是最新的「單一事實來源」？

如果我們的文件本身就是個災難，那我們就不能先怪團隊不願意去看。一個需求文件，如果讓工程師在 1 分鐘內，透過目錄和圖表或搜尋，可以找到至少滿足 80% 的資訊，那基本上可以算是一份可讀性、可用性很高的文件。

第二劑：用「連結」取代「答案」

這是最核心的行動準則。

從今天起，戒掉直接在 Slack（或任何通訊軟體） 上直接回答問題的壞習慣。

當有人問你一個文件裡有的問題時，你的回答永遠應該是一個需求文件的連結，最好是能直接錨點到對應的章節。然後附上一句：「嗨，關於這個問題，你可以參考一下我們需求文件裡的這一段說明喔！」

這樣的做法之下你既回答了問題，也同時在訓練團隊如何自己找到答案。

第三劑：在「公開場合」不斷強化文件的神聖地位

不斷地在各種會議上，強化需求文件作為唯一真理的地位。

怎麼強調呢？ 以下是你平時可以常常表達的語句，來個 洗腦 潛移默化：

• 「關於這個問題，我們來看一下需求文件上是怎麼寫的…」
• 「這個結論我會同步更新到需求文件上，大家如果忘記細節的話事後可以去查看。」
• 「如果 PRD 上的規格跟你理解的不一樣，請立刻告訴我，我們來把它修正到對。」
• 「我的確沒有更新在需求文件上，這是我的錯，這部分馬上更新。」

我們需要記得，建立一個新習慣是不會在一朝一夕內完成，可能需要幾週甚至幾個月的持續強化。我們的耐心就是最重要的關鍵，畢竟你正在改變的不只是工作流程，而是整個團隊的文化。

B 計畫

好，我們來談談最棘手的狀況。

如果你做了以上所有努力，團隊裡依然有那麼一位工程師，不管如何都堅持不看文件，把你當成他的專屬客服，該怎麼辦？（OS：老樣子先鞭數十驅之別院）

那麼我會建議你可以考慮採取這些行動：

• 私下一對一「問診」
  • 不要在大團體中挑戰他，找個輕鬆的場合，一對一地聊聊，理解他的狀況。
  • 你可以這樣說： 「阿傑，我注意到我們最近在溝通上，好像常常需要重複確認一些細節。我想了解一下，是不是我們的文件寫得不夠清楚，或是不容易找到資訊，才讓你覺得直接問我比較快？」
• 如果仍舊無效，尋求「外部會診」
  • 如果這位成員的行為，已經嚴重影響到專案的進度與團隊的士氣，而你又沒有直屬管理權，那麼你最後的手段，就是尋求他的直屬主管支援。
  • 你可以這樣跟他的主管說： 「主管，我需要你的協助。目前我們在開發上遇到一個瓶頸，團隊需要花費大量的溝通時間，來回確認規格細節，這可能會影響到我們對老闆的時程承諾。想請您協助了解一下，我們該如何一起合作，來優化這個流程？」你的溝通重點不可以放在抱怨這位工程師，而是依照事實「報告專案風險」，讓主管協助你推動改變。

最後的醫囑

所以，下次當工程師又來問你一個「PRD 裡有寫」的問題時，請先壓下你心中的白眼（好啦我知道很難，因為我也會忍不住 ☺️），因為

每一次的提問，都是一次「訓練」的機會。

你的工作本來就不是當一個有求必應的「人肉搜尋引擎」，所以透過每次提問時，你需要有耐心地打開文件、貼出連結，才能訓練團隊的「自主工作」肌肉。

當你的團隊終於學會自己走進圖書館查資料，而不是總來問你這個館員時，你才能真正地被解放出來，去做其他更有價值的事。

只要當 PM 就會不小心練成的武功：

鞭數十驅之別院！！！